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ABSTRACT 



A system with a network interconnecting a server and a 
plurality of user stations. The system automatically deter- 
mines a unique storage location for storing preference 
information for an object-oriented application, without 
resorting to the requirement of having a central authority 
assign a unique designation for the application and without 
requiring the coding of storage location information into the 
application. Th£^ervei^stqres_a^p_luralityjDf object-oriented 
end user applications for dowriloading to. user stations and it 
fiirther stores configuration ..preferences Jor the end user 
applications in the context of diJBferent groups and subgroups 
of users. A profile manager at an administrators station is 
arranged to execute a configuration application for an end 
user application, whereby the administrator can specify 
configuration preferences for the end user application in the 
context of different groups and subgroups of system users. 
When a set of configuration preferences is to be saved on the 
server, a unique location for storing the configuration pref- 
erences is determined f Qr the end ^ user application in a 
selected context by retrieving the fuUy qualified class name 
of the end user application from an objection Jhe adminis- 
tratSFilstation which represents.the_configiKation .applica- 
tion/rHen.combining the fully qualified.class name with the 
selected ^ntextao.form a key. The key is then mapped in a 
prescribed' n3iannerJo_generate_the unigue^storage^ location 
address forjhe^pplication^and^co^ 

8 Claims, 22 Drawing Sheets 
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1 

CLIENT-SERVER SYSTEM WITH CENTRAL 
APPLICATION MANAGEMENT AND USING 
FULLY QUALIFIED CLASS NAMES OF 
OBJECT-ORIENTED APPLICATIONS FOR 
DETERMINING PERMANENT SERVER 
STORAGE LOCATIONS FOR APPUCATION 
CONFIGURATION INFORMATION 

TECHNICAL FIELD 

The invention relates generally to the fields of personal 
computing and networking. Specifically, it relates to the new 
and evolving field of network computing, in which desktop 
computer users use a personal computer, possibly diskless, 
connected to a network such as a corporate intranet, the 
Internet, or to an network or Internet Service Provider (ISP) 
to gain access to applications which are then executed on the 
desktop computer. More specifically, the invention relates to 
server-based storage of software preferences (configuration 
data) for software retrieved from a server and executing at 
the desktop computer. 

BACKGROUND OF THE INVENTION 

The field of network computers is presently in its infancy. 
However, it is expected to evolve rapidly, especially in the 
corporate environment, for a number of reasons. The expec- 
tation is that as companies and possibly individual users 
reach hardware and software upgrade points, it will be more 
efiScient and less expensive to move to this new field, rather 
than upgrade in the traditional way with disk equipped 
computers and locally stored and administered software 
applications. For example, in the corporate environment, a 
user can be connected to a corporate intranet, using, for 
example, the TCP/IP and HTTP protocols of the Internet, 
and download software applications as they are needed 
direcdy from a network server to the desktop computer. An 
application is executed on the desktop in the traditional 
manner by the user to perform useful work. An advantage of 
this configuration is that network computers are substan- 
tially less expensive than traditional disk equipped comput- 
ers. It might also cost less to purchase the required number 
of software licenses for users, rather than purchase indi- 
vidual copies of software for each user. Certainly, the 
software administration problems that attend large numbers 
of corporate users will be substantially reduced. At the 
present time, each user of a disk equipped computer or 
workstation often is effectively his or her own system 
administrator, a role that often consumes excessive 
resources due to lack of expertise. It is expected to be a great 
advantage to eliminate this problem by effectively offloading 
the problem to a small number of server administration 
experts, rather than having many users struggle with the 
problems of software installation, upgrades and computer 
administration. 

As mentioned above, this vision of the future of personal 
computing is presently in its infancy. As a result, there are 
presently many problems and deficiencies with existing 
systems. 

Typically, in network computer systems, an administrator 
creates user profiles that are stored on a network server. The 
profiles may contain different types of information, such as 
user desktop preferences and user permissions for access to 
different software applications that might reside on the 
server When a user logs onto the system, the user identifies 
him or herself to the server, the server locates the profile for 
the user and transmits it to the user computer where it is used 
to configure the computer and generate a desktop. The 
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desktop might include a number of icons representing appli- 
cations to which the user presumably has access. The profile 
likely also contains other attributes of the computer and 
desktop, such as for example, the background color of the 

5 desktop, or character fonts and point sizes used on the 
desktop, or data file search paths, etc. that are unique to the 
user. The profiles may be user modifiable or non-modifiable. 

In an environment in which users can modify their own 
profiles, a modified profile is uploaded back to the server at 

10 log-off time, where it is stored for retrieval the next time the 
user logs-on. In some prior art systems, to the best of our 
knowledge, the users can generate on their desktops any 
configuration of application icons they wish, whether or not 
they exist on the server, and whether or not a user actually 

J 5 has access permission to an application on the server. The 
Lotus Workplace Desktop (previously called Kona Desktop) 
system is an example of this type of operation. In other 
systems, the server presents a list to the user of all applica- 
tions that the ser\'er has, from which the user can pick. In this 

2Q case, there is no guarantee that the user actually has access 
permission to an application that is selected from the list for 
inclusion on the desktop. The Sun Hot Java Views system is 
an example of this type of system. In other words, the prior 
an systems do not correlate between what the user can 

25 configure for the set of desktop application icons and 
applications to which the user actually has permission 
access. In such a case, when the user clicks on a icon to 
execute an application, an error message may occur (such as 
an unauthorized access message) if access permission is not 

3Q present, or in a worse case, the user's computer may crash. 
Another limitation with existing art is that a flat data 
structure is used to model users, user groups, terminals and 
groups of terminals. Modeled after a common scheme for 
managing user access to computer resources, known net- 

35 work computer implementations (e.g., Lotus Administration 
Facility for Desktops, Microsoft Windows NT Profiles and 
Policies, and Sun Hot Java Views) implement a flat "groups'* 
structure on the server for managing software preferences 
(or attributes) in various contexts. A "context", as used here, 

4Q refers to an individual user, user group, terminal, or terminal 
group. Any grouping structure for managing software pref- 
erences on the server allows an administrator to define 
preference attributes for different groups of users as well as 
for individual users. However, flat systems are inflexible in 

45 many environments, especially in environments having 
large numbers of users. It is desirable to provide an admin- 
istrative tool supporting the organization of preference infor- 
mation into a hierarchical structure. 

Another limitation with existing systems is that they are 

50 Hmited in the ways that administrators and users have to 
perform user configuration of workstation desktops. For 
example, administrators are presently required to configure 
user preferences using configuration programs that are sepa- 
rate from, but associated with, a user application. It is 

55 desirable to allow vendors to provide only a single applica- 
tion. To require only an end user application from a vendor 
necessitates that the central management facility be able to 
execute the end user application in a context of a user or user 
group. The prior art does not allow this administrative 

60 flexibility of operation. In other words, in the prior art, to the 
best of our knowledge, an administrator does not have the 
ability to run a user application in the context of a user to set 
preferences for that user and application. Further, in the art, 
an administrator cannot rm a user application to set pref- 

65 crences in the context of a group of users. 

Still another limitation in the prior art known to the 
inventors is the manner in which the prior art partitions 
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server permanent storage space to guarantee that a unique istrator ctianges the context that the application is running 

space is reserved for storing user preferences related to the under, the application needs to be relaunched to load cod- 

different applications on the server. To the knowledge of the figuration information for the new context. The process of 

inventors, the problem of preventing collisions in the storage relaunching software each time a context is changed is time 

of preference information for different applications in 5 consuming and inconvenient for an administrator, especially 

objea-oriented systems, in which an object can be queried systems with many users. In such systems, it is expected 

for its fully qualified class name which uniquely identifies that an administrator will change contexts many times whUe 

and differentiates it from other classes, is solved by having configuring an apphcation. 
a first central authority assign a unique designation that 

applies to a vendor and by then having a second authority at 10 SUMMARY OF THE INVENTION 

the vendor assign a second designation relative to the first r™ . j -u j u - -j 

, f.-t- 1 TTi^ system described herem provides a common reposi- 

designation for each vendor application. For example, ven- , c a »• • r c j 1 * - 

, t - u*i_ -1 J • J * L .1. c . tory for CO nhguration information for users and applets in a 

dorA might be assigned the designation vendorAby the first . ^ ■ . . . r 1* ni 

J *u * J • • . J. L chent-serverenvu-onment. This IS referred to as client profile 

authority and that designation is guaranteed to be unique ^ , „ , .1. * • * 

-.u- .1 u*. . r I.- L c . management. The system allows users to roam, that is, to 

within the architecture for which the first authonty is acting. 15 1^ - c * • .u * * j u 

™_ jAi. L J log-m from any computer in the system at any time and have 

The second authority at vendor A then assigns the second c j * n . j- * 

.„ . c ■ 1- L u il configured automatically at run time according to the 

designation for each of Us apphcations within that architec- n*' t^ cj 

1 r J ^ , f • 1. i. preferences stored for the user at the server. The preferred 

ture. For example, one of vendor As apphcations might be t /-i - ^ iro wx 

J . . J A A ^ i_ • . i_ J • 1 embodiment is a Java (Java is a Trademark of Sun, Inc.) 

design at ed -vendor A. Appl; another might be designated lj» . i.t_ 

J A A • J • . * r based system and the client computers use a web browser 

vendorA.App2. Fhe art maps the umque designation tor • » ^ rr-* , — - — r= — T- tm. ■ *u 

, . , ^ . , ^" mteriac e arran g ed to exec ute Java.appIicaiiOD&Jrhus, in the 

each application m a system to a location in permanent — ? — 1^ Z I " 1 . j .i_ j -rz 1 . 

r »u * . . *u . e J . r prefe rred embo diment, user applets and the desktop applet 

storage 01 the system to guarantee that preference data for ^ — TZ — r— 1 1 /^'^vj ' . * j j 

J tr . 1- J . 11- J - . * are as sumed to^bc Java applets. However, it is not intended 

the different applications do not colhde m storage. An r—t= — CTu — ~ — — ' > ^ . , , n c c 

. . ^ . , _, ^ , to limit the invention to a Java environment Preferences for 

apphcaf oD, when mamng, informs the oetwork computer loc'aUy^ored applicalions might be stored locally in the 

server of its unique storage location and it is the responsi- 5c , , . c c iT j 

. r*t. . ^T- ..u . ^* 1 traditional-manner, while preferences for the server-based 

bility of the server to partition an area at the startmg location • u* l u ji j • *i_ j l j l 

•^j. , .J, . • 1 . • 1 applets might be handled in the way described herem. 

accordmg to a context (user, user group, terminal or termma I i-r & j 

group) for storing preference information so as not to coUide mvention automatically determines a unique storage 

with preference information in a different context. Clearly, ^oc^^^<^n for storing preference information for an object- 

this manner of administering storage space is awkward and 30 apphcation, without resorUng to the requirement of 

undesirable. It is desirable to devise a method to automati- a central authonty assign a unique designation for the 

cally generate unique storage locations for storing prefer- application and without requiring the coding of storage 

ence information for the afore mentioned object-oriented locatiojuiLformation into the appUcaUon, 

applications, without resorting to the requirement of having In the preferred embodiment, the system comprises a 

central authorities assign unique designations for the pur- 35 network which interconnects a server and a plurahty of user 

pose of preventing collisions in the storage of preference stations. The server stores a plurality o f object-oriented en d 

information and without coding storage location information user applications for downloading to user stations and it 

into an application. firther stores configuration preferences for the end use r 

Still another Hmitation in the art Hes in the lack of any applications in the context ot different groups and users? A 

provision to migrate existing applications and hardware into 40 Profile manager is provided at an administrators station. The 

the new environment of the centrally managed network tyofile mana ger is arranged to execute a connguratio h 

computing world without requiring changes to the existing apphcation for an end use r apphcation, wlieiebV lUe ari min- 

hardware and apphcations. Existing hardware, a terminal for istrator can specify confipration preferences for the end 

example, in a networked environment, gets its configuration user application in the conte xt of different groups and syst em 

information at boot-up time from a file in a specific format 45 "scrs. When a set of configurat ion preterenccs is to be saved 

located on a server. The terminal is programmed to know on the server, a unique location on the server tor storing ttie 

how to access its configuration file. The terminal uses a configuration preterenccs is determined tor the end us er 

unique identifier to access the file from the server. The 'application m a selected conte xt by retnevmg _the ftiUy 

unique identifier is often the media access control (MAC) quahtied class name ot the end use r application from an 

address of the terminal. However, in a new centrally man- 50 ob[ect ^n the administrator 's station which representsjbe 

aged environment involving protocols and APPs that are configuraiion applicauon. The fully quahfied class nanfe 

different from that to which the terminal is designed, the uniquely identifies and differentiates the class from other 

terminal cannot access preference information in the new classes. The fully qualified class name is combined with the 

environment, the terminal can only access its configuration selected context to form a key. The key is then mapped in a 

file in the way for which it is designed. This is a serious 55 Prescribed manner to generate the unique storage location 

problem, because there are many such existing devices in address for the application and context. 

use. The inabihty to use them in new systems impedes BRIEF DESCRIPTION OF THE DRAWING 
substantially the incentives for users to migrate to the new 

systems. In the Drawing, 

Still another hmitation in the prior art concerns the 60 FIG. 1 shows an illustrative network and user stations, 

interface between an administrator and the configuration including an administrator's station, in which the invention 

management system. When ronfiguring software within an might be practiced; 

administration facility to configure preference information FIG. 2 shows an illustrative block diagram form of the 

for various users and user groups, and terminals and terminal administrator's station in communication with a server, and 

groups, the administration software launches in the context 65 components of the administrator's station and the server for 

(user, user group, terminal or terminal group) set by the providing the central profile management and preference 

Administrator who is running the facility. When the Admin- administration; 
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RG. 3 shows one illustrative hierarchical organization of 
user groups and users of a system. The illustrative hierar- 
chical organization might also contain individual terminals 
and terminal groups; however, these are omitted for sim- 
plicity; 

FIG. 4 shows one illustrative listing of individual users 
and the group priority order that is used to determine a set 
of preferences from the hierarchical organization of FIG. 3 
that apply to a user and a specific application executed by the 
user; 

FIG. 5 shows a more detailed view of the administrator's 
station and server of FIG. 2; 

FIG. 6 shows an illustrative view of the software objects 
at a user's terminal, including a user application and the API 
between the application and other components, that coop- 
erate to establish the user preferences during execution of 
the application as the user's terminal; 

FIGS. 7 through 8 show illustrative operations at both a 
user's terminal and a server for user log-on and initially 20 identity 
establishing the user's desktop, including desktop 
preferences, at the user terminal; 

FIGS. 9 through 11 show illustrative operations at both an 
administrator's terminal and a server for administrator user 
log-on, establishment of the administrator's desktop, and, by 25 
way of example, the selection of an application and a context 
for configuration; the example also illustrates a context 
change during configuration the user's desktop and the 
resulting operations; and 

FIGS. 12 through 24 show a variety of actual adminis- 
trator screen snapshots in various phases of application 
administration, including building of a hierarchy of which 
FIG. 3 is a representation of an example of, the creation and 
deletion of users, etc. the establishment of application pref- 
erences for applications, and context changes during pref- 
erence establishment. 



environment. The invention can be used in any client-server 
system. For example, if desired, the system could be 
designed to use proprietary communication protocols and 
applications written and compiled in any desired prograra- 
5 ming language. Further, even in the preferred Java based 
environment, disk-based computers might access some 
applications locally, and other applets from the server. 
Preferences for the locally stored applications might be 
stored locally in the traditional manner, while preferences 
10 for the server-based applets might be handled in the way 
described herein. Preferably, however, preferences for 
locally stored applications are stored on the server using the 
Profile Management Properties API in addition to the pref- 
erences for server based applets described herein. 

A simple Application Program Interface (API) allows 
ap plets w ritten to the API to easily slore_and_relrieve 
preference data whenjhe applet, is,execu ted by a user or 
administrato r. Ap plet j^rmissions_andjLiser jjreferences can 
be~llefined~based 00 group memberships and individual 
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DETAILED DESCRIPTION 

The system described herein provides a common reposi- 
tory for configuration information for all users and applets in 
a client -server environment. This is referred to as client 
profile management. The system allows users to roam, that 
is, to log- in from any computer in the system at any time and 
have it configured automatically at run time according to the 
preferences stored at the server. The preferred embodiment 
is a Java (Java is a Trademark of Sun, Inc.) based system and 
the client computers use a web browser interface arranged to 
execute Java programs. 

Hie terms "applet" and "servlet" are established terms in 
the Java programming language art and will be used herein, 



Client profile ma nagement includes the following services: 
Log-on support — mapping to a user profile; 
User^pport — the administrative ability to create user 
identifications and provide services and preferences 
directly to users; 
User-groups support — the administrative ability to create 
hierarchical groups of users and provide services and 
preferences based on group memberships; 
Use^ap plet context transpa rency — ^automatic determina- 
tion of the context of user applet.execution. That is, the 
de termi nation, of Jhe^ user^and/ot^grpup profiles Jhat 
apply_to_a.user_applet„execulion.^2aii,the_au^ 
establishment_oLthe_prQfile,enyjronm^^ 
35 User applet_ preferences repositor y — context-sensitive 
server storage for user appletjcon fig uration da ta; 
Dynamic user applet preferences inheritance — 
hierarchical load-time coalescence of user applet pref- 
erences via the object-oriented principal of inheritance; 
40 and 

User applet access control — control of user applet execu- 
tion based on group default membership privileges. 
The administrator can override default group privileges 
and permit or deny additional access privileges for 
45 individual users. 

Profile management provid es a framework through which 
ttgg ~tasks arc performed. Some tasks arc supported b y 
' protile' management dirccdy, e.g. user/group manag ement, 
ap plet lists, context switching, preference inheritance , etc., 
50 wHile configuration services specific to user applets are 
us ually supported bvsegarate configuration applets invoked 
by a system administrator within the client prolile manage - 
rnent environment. Some end user applets migk provide th e 
confi^ration capability as pan o[ the end user apple t. If this 



sipce the terms have meaning to those skilled in this aiL- 
f^pplej" i-ftffti?; ^nJndej3end&a]-SQfhvareji Mule4baLcu ns) 
I within a Java_enablcd , web brows cr ^^ rvlet refers to a 
software module that resides on a Java enabled web server. 55 is the case, me admimstralor can run the end user applet (as 
It is to be understood that the use of the terms "applet" and opposed to a separate configuration applet) in the context of 
"servlet" herein is not intended to limit the invention in any individual users and gnDups to set the configuration prefer- 
way. For clarification, the phrase "configuration applet" is enccs for those users and groups. 

used herein to refer to a software module used to configure piG. I shows one high level view of an intended envi- 

preferences for an end user software application such as a 50 ronment for practicing the invention. A network 100 is 

word processor, a database manager, etc. Since software provided for interconnecting a plurality of user stations, 

applications are also "applets" in the Java environment, the such as desktop personal computers 102, mobile laptop 

phrase ''user applet" or just "applet" is used herein to refer computers 104, workstations 106 (e.g., RISC computers), an 

to an end user application. administrator's station 108 and a ser\'er 110, In one 

In the preferred embodiment, user applets and the desktop 65 embodiment, network 100 might be a local area network. In 

applet are assumed to be Java applets. However, it is another embodiment, network 100 might include wide area 

understood that the invention is not limited to a Java networking for entities such as corporations that have geo- 
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graphically displaced sites that are still included wilhia the aiid_groups . The ProfileManagementProperties object class 

system. There is no intent to limit the environment in which proyidc^ all of the functionality of the java.util.properties 

the invention might be practiced; indeed, a network of any class with the furlhe^aMijy jo^provide^CTc^^ and 

type that interconnects many types of stations is envisioned. r etrieve the confi guratio n jnformation^Jo i^ sof tware from 

A high-level diagram of the profile management admin- s permanent storage . Storing such information in"a central 

istrative operating environment is shown in FIG. 2. An location make s maoa gcment of user and group configura- 

adrainistrator cheat network computer 200 is represented on tions possible. When a user ts in the role of administrator, 

the left of the Fig. and a server 202 for the system is on the ProfileManagementProperties 210 allows the administrator 

right. The chent and server communicate via a network to configure the user applet corresponding to configuration 

represented as 203. The particular example of FIG. 2 lO appletl, or to configure appletl if appletl is_an end ^user 

assumes that the client computer is a system administrator's ap{?let,.aDd.stQre_t he config urati on information in t he proper 

computer. place, on the server in the p roper context. Thi s allow s the 

^Pi ofile manager 206 on the client side allows the adnai n- establish menn p f j relationship ^between lihe userjppIeTand 

istrator to configure user a p pletpreferences at both user an d the user, ratherthan betw een.uscr applet and compjiteras in 

grou p levels. The administrator can create new users a nd 15 traditional systems. ftofileManagementProperties 2 iSTis^an 

grou p hierarcbies,_add users to^different^gxaups. specif y extension of the java.util.Properties class. The extension 

applet perm issions^r^ach^g roup and for individual user s. allows the key/value pairs of preference information of a 

Aji3lhe administrator c an confi g ure applets in thc context of Properties object to be associated with a key, as opposed to 

arringividuaLuser-or.„a group, 'pi e adm i ni&tra tQiijcan add, a stream, as with java.util.Properties. This, in turn, allows 

delete and reset passwords for users.^ Profile naana^ment 20 application developers to use the key to specify a unique 

support is transpareni lo the generaj us^^ location relative to a context for preference information, 

can invoke the profile manager 206 in the context of any use r rather than a file name and path. Profile ManagementProp- 

or group. Only the administrator can change trom tiis/ber erties 210 determines the key automatically. The generation 

context to administer clients (users) and groups. The server of the key is discussed more in connection with FIGS. 8 and 

will not allow a user without administrative authority to 25 9. By modeling ProfileManageraenlProperlies 210 after the 

switch context. Wh en a request comes into the ser ver, it will java.util.Properties class, the system can take advantage of 

que ry the authenticated ID , „of the user trying to access th is preference inheritance through recursive class-default evalu- 

fuq ctionT It the user does not possess admin istrative ation. Thus, this extended class provides a "group default" 

authority , (i.e., is not a member of the AllUsers.Adminis- capabiUty by accumulating preferences starting at a current 

Irator group), the Profile Manager Servlet 214 will reject th e 30 context, as discussed with respect to FIG. 3, and traversing 

r equest.^ up the contextual hierarchy for defaults. 

P rofile ma nag er ^ 206 invokes other a p plets, such as Server 202 includes a database 212 that stores user dat a 

app letl ^20 8)^ a s shown in FIG. 2. In this e xangple^^a ppletl and ^roup data^ such as user and ^roup preterences and us er 

migtit iSs the administrative applet for configy png prefer- a pplet access permissions . Webserver 218 represents a ty pi- 

ences relfitpH tn m^.t ff f fiktops. Or appletl could be a 35 caJ web server with support for Java applets. Profile Map - 

c ojifiguia^jnn uti li ty related an e.j}^ usei; applet, such as ager servlet 214 maps user and group identifications t o 

e ditors, word processors, databases. etc. It is preferredTb ut preterenc c^atjL_l t also mair^ tains an ^ cc^^^ c^jj|j^Jl^^o 

notre quired, that confi g uration.applcts^such as 208*6X^3 5 f5aiiag£-iJ5eiLacc£&'^ | flpi7|jf^f itions '^"^ jj^^^jycr.^^^^^ 

nriqdules separ ate f rom their corresponding user appjets. I n User and group preferences are stored as a tree hierarchy, 

the context of'FIG. 2, Ap_plet Us tvpicallv _juK)nfigUFatiQn 40 as shown in FIG. 3. All users of the system automatically 

ap plet for a user applet; the administrator runs the configu- belong to the top group All Users. AUrusers'belong: to the 

ration applet appletl under a group context to set group All Users p^rnup- this ^oup contains the default preference s 

preference and permission defaults, or in a user context to for some or all user applets on tne server, in hlG. 3, it is 

customize user applet configurations for an individual. By as sumed that the server contams at least three user applets, 

implementing appl etl as a module separate from its u ser 45 i dentified as ^App3. ^dd4 and Apd5. As indicated in the 

^irlni^IStlfCL'^^^^"^^- t^nhanrF.H^ <iinre. rhe. r ^nfigurat ion AllUscrs grn^P^^y^ fiarlcprnii nd (B^) for Appi ^ 

applet ]^ will lj kelyjie,si pall compared _tQ ^tbc_user^plet. BG=blue. Other illustrative preferences labeled as x, y and 

Also, separate configuration applets allow the administrator z are shown to have the default values of 1, 2 and 3 

to control the end users ability to configure the user applet. respectively. The terms x, y and z are intended to represent 

Traditional stand-alone computers store user applet con- 50 any desired preference and the values 1, 2 and 3 are arbitrary 

figuration information locally in association with its the user and used merely to illustrate the point. The x preference 

applet. Traditional stand-alone Java based computers store might for example be the sciieen font for the desktop; the 

user applet configuration information using the format pro- value x=l might call for a default font of Times-Roman, 

vided by the java.util.Properties class. Both arrangements Similarly, the defauU preferences for App4 for all users are 

require that the user applet specify the name of a local file 55 BG=gray, x=2, y=2 and z=2. 

in which to store configuration information related to the The default values in the AllUsers group can be modified 

user applet. In other words, a relationship is required in any desired way for other contexts, such as for other user 

between the computer and the user applet loaded on it. groups and individual users. By way of example, in addition 

Profile management as described herein provides the famil- to the context of AllUsers in FIG. 3, four other groups 

iar capabilities of a real java.util.ftoperties object plus 60 (GroupX, GroupY, GroupYl and Group Y2) are shown, 

additional facilities supporting user-roaming capabilities Additionally, two individuals Userl and UserN are shown, 

and seamless pluggabiUty into a powerful administrative Users can be members of more than one group. In FIG. 3, 

framework (the Profile Manager). Userl is a member of AllUsers, GroupX and GroupYl; 

ProfileManagementProperties P 210 js_a,pro perties_oty ect UsenN is a member of AllUsers and GroupY2, If a user is 

for^p pjetl and^ pr avides an API between Appletl and the 65 a member of more than one group (another group in addition 

server that allows the server to detejrni n e where to st o re to AllUsers), then the groups are prioritized for the purpose 

configu j^o a-informatio ri for appletl uHhe context of users of selecting the preferences for a given applet for that user. 
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The administrator configures the group priorities for a user. FIG. 4 shows that the highest priority group for Userl is 

Group priority is illustrated in FIG, 4, In FIG. 4, Userl has AllUsers.GroupX; this branch of the group hierarchy will be 

GroupX (identified by the fully qualified name of AllUsers- checked first for preference information pertaining to App3. 

.GroupX for his or her highest priority group. Userl^s next From here on, the example is essentially the same as 

highest priority group is GroupYl 5 example 1 above, except that the coalesced set of prefer- 

(AllUscrs.GroupY.GroupYl). Userl 's lowest priority group ences is used to configure App3 on the user's workstation, 

is the AllUsers group. When a user, say Userl. requests to The preferences for App 3 for User are: BG=Green, x=l, 

run an applet say App3, the preferences are coalesced from y=2, z=3 since the 'B6=Green preference stored in the 

the tree of FIG, 3 according to the group or groups to which Userl 's context for App3 over rides the default BG-Blue 

the user belongs and the user applet is configured on the user lo preference obtained from the AllUsers.GroupX branch of 

desktop accordingly, the preference tree. 

The first step in coalescing preferences for any context is Example 3: Coalescing preferences for com.ibm.App6 in 

to get the defaults. The defaults for a user, if there are any, the context of Userl. 

is the coalesced set of preferences for the applet from the This example illustrates the situation of the highest pri- 
highest priority group from which preference information 15 ority group containing no coalesed preferences for the 
for the applet can be obtained. The defaults for a group, if contextof Userl. Again, the highest priority group for Userl 
there are any, is the coalesced set of preferences for the is GroupX. This group and its parent AllUsers contain no 
applet from the groups parent (i.e., The AllUsers group is the preferences for App6. Therefore, the next highest priority 
parent of AllUsers.GroupX). If a group has no parent (i.e., group is searched. The next highest priority group for Userl 
the top level AllUsers group), there are no defaults for that 20 is GroupYl. A set of preferences can be obtained from this 
group. To coalesce the preferences for an applet at a context, group for App6. The coalescence of preferences proceeds as 
the preferences for the applet explicitly stored at the context, described in example 1. Recursive calls are made from 
overwrite the defauU preferences for the applet for the GroupYl up the tree to the root AllUsers group and the 
context. Thus, to coalesce preferences into the default set for preference sets are returned back down the recursive calls 
an applet in a group context, recursive calls are made from 25 and modified along the way to form the default set. The 
each group node up to the AllUsers group requesting each default set is then modified with the preferences stored in 
parents set of preferences for the applet. Please refer to FIG. GroupYl to form the coalesced set of preferences that apply 
3 to illustrate the following example. For example, if the to this context. Stated briefly, Allusers returns a null set of 
context is Allusers. Group Y GroupYl, a call is made to the preferences, since it has no preferences for App6. Group Y 
parent of GroupYl, which is Group Y, requesting its default 30 modifies this null set with the values a-1 and b«2 and 
preferences for the applet. GroupYl makes a recursive call returns this set to GroupYl as the default set. GroupYl 
to its parent, which ts AllUsers. AllUsers has no parent, so modifies the default set with a=33. This set is returned to the 
AllUsers returns it set of preferences for the applet to the call Userl context for use as its default set. Since there are no 
from Group Y. This set of preferences is modified by the preferences for App6 stored at the Userl context, the 
preferences stored in GroupY for the applet, if any. This is 35 defaults obtained from the GroupYl branch of the prefer- 
now the default set of preferences for the applet for the ence tree represent the fully coalesced set of preferences for 
context of GroupYl. This set of default preferences is App6. The real set of preferences thus becomes a=33, b=2 
returned to GroupYl as a result of the recursive call from for this context. 

GroupYl to GroupY, and are modified by the preferences at The above 3 examples described the gathering of prefer- 

GroupYl for the applet, if any, to become the actual set of 40 ences in response to a load( ) for a particular piece of 

preferences to be used in this instance. The set of preferences software. When preference information is saved for a piece 

for the context of a user is built in the same way, except that of software, any preferences that have been expUcitly writ- 

Ihe highest priority group from which preference informa- ten at the Context being saved to will be written to the data 

tion can be obtained for the user is used to first establish the store (212) at the location specified by the combination of 

group context from which the defaults will be obtained. 45 the Context the software is being run in and the key for the 

Then the recursive procedure described above is used to software whose preferences are being stored, 

build the actual set of preferences for the user and the applet Permissions operate similarly: a new group has access to 

requested by the user. all the applet names permitted by the group itself as well as 

The following examples illustrate the above preference to all applets permitted by its supergroups. However, just as 

coalescence and should be read in conjunction with FIG. 3. 50 Java allows the programmer to override a superclass 

Example 1: An administrator runs a configuration applet method. Profile Management allows the System Adminis- 

for App3 to set preferences for the group AllUsers.GroupX, trator the ability to override an inherited permission. This is 

To set the preferences for App3 in the context of called overriding a permission. 
AllUsers.GroupX, the present set of preferences must be As with Java's form of inheritance. Profile Management's 
determined, AllUsers.GroupX requests defaults for its par- 55 form of preferences and permissions inheritance is called 
ent AllUsers, Since AllUsers is the top level group, it returns single inheritance. Single inheritance means that each Pro- 
its preferences for App3 to GroupX. These are the default file Management group can have only one supergroup 
preferences for App3 in the context of GroupX. Since (although any given supergroup can have multiple 
GroupX has no preferences for App3, the default set from subgroups). 

Allusers is the real set of preferences to be used. In this 60 Profile Management users (leaf nodes) may require mem- 
example, these preferences from the AllUsers group are: bership in multiple groups, so a facility is required to limit 
BG=Blue,x=l,y=2,z=3. The administrator can now modify preference inheritance to a single hierarchical group to 
use the configuration applet to modify the coalesced pref- minimize the chance of corrupt configurations due to the 
erences in any desired manner. introduction of incompatible variable subsets introduced by 
Example 2: Userl requests execution of com.ibm.App3. 65 cross group branch coalescing. By allowing a user's group 
Preferences must be coalesced for com.ibm.App3 in the memberships to be prioritized, profile management can 
context of Userl. follow a search order when looking for preferences related 
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to a particular applet. In other words, starting with the group 
with the highest priority, the search will stop at the first 
group found to contain configuration data for the applet 
attempting to load its preferences. 

A user inherits software permissions from group mem- 
berships. With careful enterprise modeling, the administra- 
tor can assign software access to many users without having 
to navigate through panels, one user at a time. Profile 
management controls access by programming the web 
server to permit/deny access to applets. The web server 
enforces the access control. The profile manager servlet is 
also protected by the Webserver requiring user ID's and 
passwords to be passed to the webserver for authentication 
purposes. It is standard browser functionality to prompt for 
user passwords as required. 

FIG. 5 shows the system of FIG. 2 in more detail. 
Configuration applet Apple tl is invoked by the administra- 
tor within the profile management framework. Appletl may 
implement the application program interface (API) 515 for 
querying information about its operational environment 
(e.g., query context, context changed events, query access 
control list for this context, etc.) to integrate tightly within 
the profile management framework, but this is not a require- 
ment for a configuration applet. In any event, the designer of 
appletl need only understand the basic API methods: 
enable Persistence( ), load( ), and save( ) in addition to the 
basic methods of a java.util. Properties object used to get 
preference information into and out of a java.util.Properties 
object. API 515 additionally provides list( ) and getcontext() 
methods. Appletl need only register with the ProfileMan- 
agementProperties class and call these methods as appro- 
priate. The load( ) method can be called to retrieve the 
present state of preferences for the user applet being con- 
figured in the context of a user or group selected by the 
administrator The administrator can then modify the pref- 
erences as desired and store them using the configuration 
save functionality provided by the applet (which uses the 
sav6( ) method of its Profile Ma nagementProperties object. 
Similarly, if appletl needs the list of user applets authorized 
for access by a user, it can use the list( ) method to obtain 
the list from the server. The getcontext( ) method can be used 
by the applet to display the name of the context that it is 
running in or even to ensure that it only runs in a certain 
context (i.e., if an applet wanted to configure a service on the 
server using the export agent, it might only allow itself to be 
run at the AllUsers context since the configuration being 
exported is server specific as opposed to user specific. For 
appletl to run in the profile management framework, all that 
is required is for the applet to register with ProfileManage- 
mentProperties 410 and implement the ProfileManagement- 
Properties class, an extension of the java.util. Properties 
class. 

The profile manager 506 also provides a context change 
API 516 for configuration applets. Appletl may implement 
a context change event listener 512. The API 516 and the 
event listener 512 allows the administrator to change con- 
texts (user or group) while nmning the configuration applet, 
without having to stop and restart it. For example, when 
configuring applet user preferences, the administrator will 
likely change contexts many times during the configuration. 
If the configuration applet is registered as a listener to such 
events, profile manager 506 will notify it of a context change 
via API 516. This allows appletl to refresh its preferences 
from the server for each new context. Without the event 
listener API, appletl would have to be terminated by the 
administrator and restarted after a new context has been 
selected to reference the existing preference information for 
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the new context and avoid being stopped and restarted by the 
Profile Management applet. To register, appletl calls a 
method on its properties object ProfileManagement Proper- 
ties 510 i.e., add ContextChange Listener (API 516) to reg- 

5 ister itself. When the administrator sets a new context, 
profile manager 506 performs a set context call (API 516) to 
object 510, which in response calls the reload method (API 
516) on event listener 512. Event listener 512 now performs 
a load properties call to its properties object 510 to gel the 
new preference data from the server for the new context, and 
causes applet l to updates it GUI and internal variables t o 
reflect TfiB iieiv preference intormation . 
^ above functionality avoids tbe possibility of a net- 
work administrator reading data from one context, changing 
context, and accidentally overwriting with a save( ) when 
intending to load( ) before making configuration changes in 
the new context. 

Applets that do not register as listeners will be stopped, 
destroyed, reloaded, and restarted by the profiJe manager 
applet when the administrator forces a context change. 

20 The profile management also provides a "properties 
export" service to allow the easy retrofitting of existing 
hardware and software into this profile management envi- 
ronment. The properties export service allows profile man- 
ager 514 to support user workstations (the physical 

25 hardware) as well as users, groups, and user applications. 
Since existing workstations do not know about ProfileMan- 
agementProperties 510, the export service allows worksta- 
tion vendors to create workstation-configuration applets that 
specifies an export agent 520 to be invoked on the server 

30 when the vendor applet saves it preference information. The 
export tag causes an instance of a vendor-supplied class (the 
export agent 520 object) to be created and the export method 
to be invoked on the object to specify that workstation 
configuration information be saved in whatever proprietary 

35 file format and/file location(s) that are required by the 
workstation being configured. 

Assume that appletl is the configuration applet provided 
by a vendor for an existing terminal that is incompatible with 
the present profile management system. The vendor also 

40 supplies export agent 520. An administrator can configure 
the terminal for operation in this system by running profile 
manager 506, set the context to the terminal being 
configured, runs the vendor supplied configuration appletl 
and configures the applet. When the administrator saves the 

45 configuration, part of the information that is transmitted to 
the server is a unique identifier that identifies the terminal 
being configured. Typically, this is the Media Access Control 
(MAC) address of the terminal. Profile manager servlet 514 
detects that an export agent is specified on the save. Profile 

50 manager servlet 514 detects this from one of the preferences 
being saved that specifies need for the export agent. The 
preference specifies the export tag in the form of a key value 
pair of 

XXXXEXPORT_AGENTXXXX={fully qualified class 
55 name of export agent} 

The Export Agent's export(Context context, config 
properties) method is called by the profile manager servlet 
514 to create one or more files 522 on the server from the 
save preferences information. The specific file or files are 
60 identified by the unique identifier of the terminal that came 
with the properties information from appletl. When the 
terminal later boots up, it uses its unique identifier to locate 
and retrieve its configuration information from files 522 on 
the server in the same manner that it always did, independent 
65 of the profile management system. 

FIG. 6 illustrates an applet2 mnningon a client computer. 
Applet2 might be an end -user applet such as a word pro- 
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cesser In any event, applet! has access to some of the the Continuing oq at FIG. 8, at 800 the Desktop object reads 
same API methods as shown at 515 of FIG. 5 if it desires. it*s preference information out of its ProfileManagement- 
Applet2 uses the load method to retrieve preferences and the Properties object P, and begins to update the desktop accord- 
save method to save any preferences that might be changed ingly (i.e., it might set the screen color to blue, get infor- 
by the end user. Enable Persistence initializes the Profile 5 mation about the position of icons, etc.). The desktop object 
Management Properties object for applet2 with context calls a method on its ProfilcManagementProperties object P 
equal to the user and generates the unique key for identifying to get a list of the software to which the user has access 
the preference information storage location on the server, as permission. The ProfileManagmentProperties object P 
described above relative to the administrator, requests the information at 802 from the profile manager 
t'IG. 7 shows the situation of a user bringing up his or her lO servlet 214, which generates a response with the requested 
desktop. The user on the client (700) points his or her web information at 804. For each such applet to which the user 
browser at the URL of the desktop applet on the server and has access, the information includes a user friendly name, 
at step 704 sends a message http://server/Desktop.html). the applet's URL, the URL of an icon for the applet, etc. 
Since Desktopjtol i s a file tbat„the_seryer_prptects, a (information that is required for the desktop to represent the 
challeng e is sent bac k_ to the web browser on the client at 15 applet on the desktop and to load and launch it), and other 
70 6. The web browser on the c lient rcsponds-by..prompting optional material which is not relevant to the invention. This 
the^usrr for- aoiae r^ID an d p assword. The client then sends information is stored in the ProfileManagmentProperties 
{pQ user ID and password mtormation to the_ server at 7 08, object P, and returned to the desktop object. At 806, the 
T he user ID and password, ar&.sbQ_wa_in_boId!at _708 bf"F IG. desktop object uses the applet information to build a folder 
3^jojl lustra te thai thig infomnatinn. passer^ by weh 20 for the applets and to generate a window displaying the icons 
b rowser itself . This type of nomenclature is used in other and the user friendly name for each applet to which the user 
places to illustrate the same thing. Since, presumably, the has access. 

user has permission to run the desktop applet, the request Assume that in a previous run of the desktop by the user, 
will be honored. the user dragged and dropped the icons for some of the 
There are a series of interactions between the client and 25 software displayed in the folder that was just descr^jed. It is 
the server (not shown) where the code for the desktop applet possible that at this time the user no longer has access to the 
is loaded to the client from the server. The desktop object is applets that were dragged and dropped from the folder to the 
created and begins to execute at 712. The desktop object desktop. However, these desktop objects normally would be 
needs ^ts preference info rmation (i.e., configuration a part of the users preferences that were saved during the last 
informatioHy' sd it can tail or the deskto p for the end user w ho 30 run and would still be displayed on the desktop. To avoid 
is iayokio g it. To th is end, as part of the desktop object's this situation, the desktop examines its preferences from it's 
initialization process, the desktop creates a ProfileManage- ProfileManagmentProperties object P to check for applets 
mentProperties object P at 714, which is used to load, get, that are configured to appear outside of the window that is 
cache, set, and save a copy of the user's preference infor- generated to display all applets to which the user has access, 
mation from the server for the desktop applet. The desktop 35 FIG. 8 assumes that there is only one applet outside of the 
object then performs an API call PenablePersistence applet window that is genera ted. If the re we re more than one 
(desktopObject (applet)) at 716, which, at step 1) of 716, such applet outside of the applet window, the following 
initializes the ProfileManagcmentPropcrties object P with procedure would be looped for each such applet. At step 810 
the URL of the profile manager servlet 214. This URL is the desktop checks each of these applets appearing outside 
derived from the URL of the desktop applet that was loaded 40 of the applet window against the list of applets from the 
from the server previously. The ProfileManagementProper- server to which the user has access. If the applet appears in 
ties object P sends a request 718 to the profile manager the list, the icon for the applet is placed on the desktop at 810 
s ervlet 214 to g et-ihe-context~fQt_lb e_ liser running the in the same position as before. If the user no longer has 
d esktop a pplet. In this case, the context consists of two access to the applet, the applet is removed from the desk- 
components, a context name which is the ID of the user, and 45 top's preferences at step 814 and removed from the Profile- 
a context type which in this case is User. The profile M a nagment Properties object P If any applets are removed 
man ager servlet gets the ID of the user from the reque st"7I8 as part of this process, the desktop tells the ProfileManag- 
aiia~Tctums the user context at 719. At step 2 of 716, the mentProperties object P to save the preferences at step 816. 
ProfilcManagementProperties object P is initialized with the The ProfileManagmentProperties object P sends a request 
context of the user running the desktop. At step 3 of 716, the 50 818 with the preference, key, and context information to the 
ProfilcManagementProperties object P generates a unique profile manager servlet 214 to save the new preferences 
key for the desktop software by asking the Java desktop information in the Database 212. The server sends a 
object P for its fully qualified class name. All Java objects response 820 to the ProfileManagmentProperties object P 
know their class name. This unique key is combined with the informing the ProfileManagmentProperties object P that the 
user's context information to provide a parameter that 55 request was successfully completed. 

specifies a unique location in the database 212 for storing the FIG. 9 illustrates the situation of an administrator running 
user specific preference information for the desktop applet. a configuration applet to configure preferences for an applet 
Any desired method can be used for mapping the string for other users or groups of users. It is understood that the 
consisting of the fully quaUfied class name and the user principles discussed here also apply generally to the con- 
context information into the data store location. Next, a 60 figuration of terminals or groups of terminals. The admin- 
request 720 is sent to the 4)rofile manager servlet 214 to g et istrator on the client 900 points his or her web browser to the 
the preference in f ormation, tailored for the user, for the URL of the profile manager applet 214 on the server, which 
Desktop applet, t ne contex t and key are passea as pan ot tne is to be run. The URL is sent to the server at 904. Since 
reciuest 72U to identity the requested preference information. ProfileManager.html is a file that the server protects, a 
The profile manager servlet 214 responds with the requested 65 challenge 906 is sent back to the web browser on the client, 
preference information at 722, which is cached in the The web browser responds by prompting the administrator 
ProfilcManagementProperties object P 604. for a user ID and password. The request to get ProfileMan- 
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agerhtml is then repealed at 908 to the server with the user 
ID and password information included in the message. Since 
presumably the administrator has permission to run the 
profile manager, the request is honored and a profile man- 
ager applet is downloaded to the administrators terminal at 5 
910. There are a series of interactions between the client and 
the servxr (not shown) where the code for the profile 
manager applet is loaded to the client from the server. The 
profile manager object is created and begins to execute at 
step 912. 

A ProfileMaQagementProperties_nonContext Floating is 
used by the profile manager instead of a normal ProfileM- 
anagemenlProperties object. It has the same behavior as a 
FrofileManagemenlProperties object with one exception: 
when preferences are loaded and saved, they are loaded and 
saved to and from the context of the administrator who is 
running the profile manager, as opposed to loading and 
saving to and from the context (i.e., user or user group) for 
which the administrator is configuring. 

The profile manager object needs its preference informa- 
tion (i.e., configuration information) so it can tailor the 20 
profile manager for the administrator is invoking it. To this 
end, as part of the profile manager object's initialization 
process, the profile manager creates a 
Profile Man a gementProperties_nonContextFIo at ing object 
P_NCF at step 914, which is used to load, get, cache, set, 25 
and save a copy of the administrator's preference informa- 
tion from the server for the profile manager applet. The 
profile manager object then calls P_NCF.enablePersistence 
(profileManagerObject(applet)), which in step 1 of 916 
initializes the ProfileManagementProperties_ 30 
nonContextFloating object P_NCF with the URL of the 
profile manager servlet 214. This URL is derived from the 
URL of the profile manager 10 applet. The 
ProfileManagementProperties_nonContextFloating object 
P_NCF sends a request 918 to the profile manager servlet 35 
214 to get the context name (ID) of the administrator and the 
context type (USER). The profile manager servlet gets the 
ID of the administrator firom the request (918). The web 
browser passes the administrator ID and password in the 
message along with the information sent by the 40 
Profile IVlanagementProperties_nonContextFloating object 
P_NCF. The ProfileMaoagementProperties_ 
nonContextFloating object P_NCF is initialized with the 
context of the administrator running the applet at step 2 of 
916. At step 3 of 916, the ProfileManagementProperties_ 45 
nonContextFloating object P_NCF generates a unique key 
for the profile manager applet by asking the Java profileM- 
anagerObject object (passed as a parameter in the enableP- 
ersistence call) for its fully qualified class name (i.e., 
profile ManagerObject.getClass( ).getName( )). This unique 50 
key, combined with the administrator's context information, 
is mapped to specify a unique location in the database 212 
for the administrator's specific preference information for 
the profile manager applet. 

A request (922) is sent to the profile manager servlet 214 55 
to gel the preference information tailored for the profile 
manager applet as configured for the administrator. The 
request (922) includes the appropriate context name and 
type and key information to identify the appropriate prefer- 
ence information. The profile manager servlet 214 responds 60 
with the requested preference information (924), which is 
cached in the ProfileMaQagementProperties_ 
nonContextFloating object P_NCF. The profile manager 
reads its preference information out of the 
ProfileManagementProperties_nonContextFloaiing and 65 
updates itself accordingly (i.e., sets its background color to 
blue for example). 
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Operation continues at FIG. 10. The profile manager 
requests the infonmation about existing users, user groups, 
and software from the profile manager servlet 214 and builds 
the tree in the left panel of the profile managers configura- 
tion window at 1002. See FIGS. 13 through 24 for examples 
of the administrator's left panel. At this point 1004, the 
administrator selects a desired context for configuring by 
clicking on a user or group from the left panel tree. The 
profile manager sets the context for PtofUeManagement- 
Properties objects by calling P__NCFsetContext(selected 
context). See FIG. 13 for a selected context of "User 
Groups", which refers to the group of all system users, or to 
FIG. 18, where a group context of "Development" is 
selected, or to FIG. 21 where a user context "colleend" is 
selected. Next, at step 1006, the administrator selects an 
applet to be configured from a list of all the applets on the 
server. See FIG. 17 for an example of selecting an applet. At 
step 1008, the administrator then clicks a Run/Customize 
button to run the applet selected for configuration. This 
applet might be a separate configuration applet for an end 
user applet, or it might be the end user applet itself. The 
selected applet is requested and loaded from the Server at 
1009 and 1011. At step 1010, the configuration applet c^ject 
is created and begins to execute and to generate its Profde- 
ManagementProperties object P. 

If it is assumed that the applet is a separate configuration 
applet for an end user applet, then at step 1012, the applet 
calls p. enablePersistence(configApplet Object, 
fullyQualifiedClassNameOfAppletBeingConfigured). On 
the other hand, if the applet is a user applet, rather than a 
separate configuration applet, the call would be 
p.enablePersistence(endUserAppletObject) since it wants to 
configure its own preference information as opposed to the 
preference information for another applet. The current Con- 
text is already known by the ProfileManagementProperties 
object P since it was previously set by the administrator via 
the administrator's ProfileManageracntPropcrties_ 
nonContextFloating object PM_NCF. The location of the 
profile manager servlet 214 was previously generated when 
enablePersistence was called on the Profile Managers 
Prof51eManagementProperties_nonContextFloating object 
PM_NCF. In the case of a configuration applet, the unique 
key for the applet does not need to be generated because it 
is passed by the configuration applet to the ProfileManage- 
mentProperties object P in the enablePersistence call. 

At step 1014, the configuration applet registers itself with 
its ProfileManagementProperties object P as a context 
change listener. As discussed earlier, this allows the applet's 
ProfileManagentProperties object P to notify the applet if the 
administrator makes a context change so that the applet can 
load the preference information for the new context and 
update its Graphical User Interface to reflect the new con- 
figuration information, without requiring that the applet be 
terminated and relaunched in the new context. 

Operation continues at RG. 11. At step 1104, the con- 
figuration applet tells the ProfileManagementProperties 
object P to load the preferences from the current context for 
the applet being configured. A request 1105 ts sent to the 
profile manager servlet 214 to get the preference 
information, tailored for the context previously selected by 
the administrator, for the applet being configured. The 
request 1105 includes the appropriate context name (the 
context the administrator has selected) and the context type 
(USER, USER_GROUP, or ALL_USERS_GROUP as 
appropriate) and key information to specify the location of 
the appropriate preference information. The profile manager 
servlet 214 responds with the requested preference informa- 
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tion at 1106, which is cached in the ProfileManagemeni- "Applet name" field displays this applet name. The "URL" 

Properties object P, The configuration applet gets prefer- (Universal Resource Locator) field displays the Intranet or 

ences from the Profile ManagementProperties object P and Internet web address of this applet on server 202. The field 

updates its Graphical User Interface accordingly. "Complete path of html file" displays the directory path and 

The administrator configures the applet at 1107 and saves 5 file o^me of the applet in the disk directory slruciure of 

the modified preferences, for example by cHcking a SAVE server 202. The field "FuUy qualified class name^ displays 

button provided by the applet. As a result of this operation. ^^e ftiUy qualified class name of the applet. The field "Icon 

the configuration applet calls the save( ) method on its ^"^^^^P ^ web address of the image file used to 

ProfileMaoagementProperties object p. The ProfileManage- ^° ^^^^^^ ^PP*^\ "^.^ ^l^^^^P- 

*n_« u- . n J .u f J fu remammg fields are for optional information that may be 

mentProperties obiect P sends the preferences and the lo j . c. • • a j 

i r.u i.L- c J j*L-f required by the software upon invocation. A command 

unique key for the applet bemg configured and the mfor- ^3^^ j^f ^ist from FUe", allows the 

mation specifying the current context to the profile manager administrator to append definitions of applets to the existing 

servlet 214. The profile manager servlet stores the prefer- ^j^g f^^m an existing text file. When button 1310 is 

ence mformaUon m the database 212 in the location speci- ^^^^^^^ ^^e window shown in HG. 14 pops-up and allows 

fied by the Context and the key. 15 the administrator to enter the path and file name of the text 

Step 1108 is an example of the administrator now chang- file containing the applet definitions to be appended. To save 

ing context, while the configuration applet is still running. all pending changes, the administrator clicks on File 1312 

The administrator selects a new context by clicking on a user and then Save (not shown). 

or user group (see FIG. 18 for examples of new contexts in In the left panel, the User Groups item 1302 corresponds 
the administrators left screen panel). As a result of the 20 to the AllUsers group of FIG, 3 ("User Groups" and "AllUs- 
context change, profile manager 506 sends a set context ers" are used interchangeably herein). FIG. 15 shows the 
message to ProfileMangementProperties object P (510) by right panel of the administrators station when the "User 
calling P_NCF.se tContext(selected NEW context), which Groups" item 1302 is selected. In FIG. 15, a notebook panel 
in turn causes object P to notify event listener 512 of the is displayed on the right that contains three tabs — a Mem- 
context change via the reload properties API 515. This 25 bers tab 1514, a Subgroups tab 1516 and an Applet Per mis- 
occurs at step 1110. At step 1112, the event listener 512 sions tab 1518. The Members tab is selected in FIG. 15. The 
performs a load( ) call to retrieve the preferences for the new Members panel contains a list 1520 of the log-on identifi- 
context and the object P is updated with the new preferences cations of all members that have been defined to the system, 
at step 1118. The administrator can now proceed to modify To create a new user (who will automatically gain member- 
the new preferences for the new context, if desired, and to 30 ship into the presently selected group context — ^'*User 
save them if required, and then to proceed on with a new Group"), the administrator selects <NEW> from the list 
context change if necessary as described above. 1520, enters the appropriate information in the entry fields 

The remaining FIGS. 12 through 24 show actual screen 1522 to the right of the list, and then clicks on the Create 

snapshots of an administrator's workstation while running button 1522. When an existing member is selected from the 

portions of the profile manager 206. 35 list 1520, the attributes previously saved for that user are 

The main configuration window 1200 is shown in FIG. displayed at 1522. These attributes include the full name of 

12. The tree view panel 1202 on the left of the window the selected member, the member's system ID, password 

depicts profile management 1204 as one of several services and any desired comments. The attributes, except ID, may 

available on the server. When this item 1204 is selected as be edited and the changes committed (but not Saved) by 

shown in FIG. 12, the right panel 1205 of the main window 40 clicking the Modify button 1524, or the user may be 

displays a welcome message for the profile management removed from the system entirely by clicking the Delete 

service. Expand and contract icons such as 1208 are used to button 1526. Any pending change may be removed by 

control the appearance of sub-items under an item in the left selecting the entry in the list 1520 and clicking the Undo 

panel, if any exist. The in 1208 is caUed an "expand button 1528. 

icon" and indicates that there are sub-items beneath "Profile 45 FIG. 16 shows the administrator's right panel that is 
management". The administrator can display these sub- displayed when the Subgroups tab 1516 is selected. Sub- 
items by clicking on the expand icon 1208, which vail then group list 1620 shows existing groups that are subgroups of 
become a "contract icon" ("-")• the item selected in the left panel, which is "User Group" in 
FIG. 13 illustrates an expansion of the Profile manage- this example. Therefore, Ust 1620 displays all immediate 
ment item 1208 in FIG. 12, which results in the display of 50 subgroups of the "AllUsers" group. In the left panel, "User 
three default sub-items in FIG. 13 — "Applets" 1300, "User Groups" is expanded. The subgroups shown in list 1620 are 
Groups" 1302 and "Users" 1304. Expansion icons indicate also the expanded items under "User Groups" in left panel, 
that these items can also be expanded. "Applets" 1300 In list 1620, a status field shows the present status of each 
allows the administrator to define the user applets available subgroup, such as "! delete", "! Modify^', and "! Create". An 
on server 202, "User groups" 1302 allows the administrator 55 empty Status field in list 1620 indicates that the subgroup 
to create and populate the user group tree of FIG. 3 and to exists and no actions are pending to be saved. The 
set group preferences. "Users" 1304 allows the administra- symbol indicates that the status is pending (not yet saved), 
tor to create new users and to set their preferences or to Attributes for the subgroup selected in list 1620 appear in 
change preferences for existing users. In the example of 1622. These attributes include the subgroup name and 
FIG. 13 "Applets" 1300 is selected. When this item is 60 desired comments about the subgroup. To create a ikw 
selected, panel 1305 on the right of the window displays a subgroup, the administrator selects <NEW> from list 1620, 
list 1306 of user applets that have already been defined to the enters the subgroup name and desired comments in 1622, 
system. Attributes of the application that is selected in 1306 and clicks the Create button 1628. An entry of "! create 
are shown at 1308. The administrator defines a new applet <subgroup name>" then appears in list 1620 as a pending 
by selecting <NEW> in 1306 and entering the name and 65 action. To save all pending changes, the administrator clicks 
location information requested in 1308. An existing applet the File button in the top menu bar and then Save (not 
"Database Explorer" is shown selected in 1306. At 1308, the shown). 
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FIG. 17 shows the right panel that is displayed when the 
Applet Permissions tab 1518 is selected. List 1720 shows all 
names of all applets that have been defined to the system and 
the permission status (permit or deny access) that is assigned 
to each applet for the group or subgroup (the current 
"context") that is selected in the left panel. As with other 
notebook pages described, an exclamation point indicates 
that the status depicted is a change that is pending a Save. 
In FIG. 17, the group "User Groups" is selected in the tree 
shown in the left panel, which corresponds to the " AllUsers" 
group shown in FIG. 3. Since all users of the system have 
membership in the "User Groups" group, list 1720 shows the 
global default permissions for all system users for each 
applet defined to the system. For example, the default 
permission status for applet "Database Explorer** is "permit** 
(meaning access is permitted) for the "AllUsers** group; 
similarly, the default permission status for all users to applet 
TFTP is "deny** (access is denied). The administrator can 
change the permission status of an applet by selecting it in 



or delete an existing member, the administrator clicks on the 
"Create/Modify/Deleie Users** button button 1840, This 
action brings up the notebook page shown in FIG. 19. The 
right panel of FIG. 19 is similar to that of FIG. 15 and allows 

5 the administrator to create a new system user by selecting 
NEW in list 1920 and then clicking the "Create" button. 
Similarly, the administrator can modify or delete an existing 
system user by selecting the appropriate user in list 1920 and 
clicking the appropriate button "Modify" or "Delete". Users 

10 created at any subgroup context (e.g., "Development'*) not 
only gain the required membership in "User Groups", but 
are automatically made members of the selected subgroup. 
Changes to the system user list are saved by clicking on 
"File** in the top menu bar of the right panel and then 

15 clicking "Save" (not shown). 

FIG. 20 shows a direct way to get to the system user list 
for editing, rather than through the group and subgroup route 
shown in FIG. 19. To get to FIG. 20, the administrator 
selects "Users** 1304 in the left panel of FIG. 13, for 



list 1720 and clicking the "Permit group access** button 1730 20 example. Then in the right panel shown in FIG. 20, the 



or the "Deny group access*' button 1732. Furthermore, 
regardless of an applet's permission status for the selected 
context, an administrator can select an applet from 1720 and 
click the "Run/Customize" button 1734 to execute the user 
applet under the selected context. The panel region previ- 
ously showing the notebook for the current context then 
becomes occupied by the executing user applet. If the user 
applet happens to be a configuration applet for other 
software, the administrator can then save software prefer- 



administrator can create new users and modify and delete 
existing users, as already discussed, without being in the 
context of a group or subgroup. 

In FIG. 21, the administrator wishes to work directly on 
25 information corresponding to a user whose ID is "coUeend". 
To do this the administrator expands "Users" in the left panel 
of FIG. 21, for example, and then selects "coUeend**, as 
shown. The right panel then appears, which is devoted to 
coUeend *s system information. The right panel contains 



ences (through the configuration applets unique facilities 30 three tabs. The first tab "User Information*' is selected by 



provided for this function) which will then be saved as the 
software *s default preferences for the selected context. If the 
applet is an end user applet, the functions are the same, 
except the end user applet loads and saves it own preferences 
rather than preferences for a separate piece of software. 

FIG. 18 shows the complete expansion of the adminis- 
trators left panel subgroup tree beneath "User Groups". 
Immediately beneath "User Groups", there are two sub- 
groups "Administrators", a default subgroup that cannot be 



default. In this lab, the administrator can modify the name, 
ID, password and comments pertaining to colleend. 

FIG. 22 shows the right panel when the administrator 
selects the second tab "Group Memberships". List 2220 
35 shows all subgroups of which colleend is a member. The 
subgroups are shown in this list in the order of subgroup 
priority for colleend. The administrator can change col- 
leend's subgroup priority by selecting a subgroup and using 
the up and down arrows to the right of list 2220 to move the 
removed, and "IBM", a subgroup defined by the admin is- 40 selected subgroup up or down the list as desired. If the 
trator. The "IBM" subgroup has also been expanded and administrator clicks the "Add/Remode Group Member- 
contaitK three subgroups "Hardware", "Services" and "Soft- ships'* button 2242 in FIG. 22, the right panel then shows the 
ware". The "Software" subgroup has been expanded and contents of FIG. 23. The FIG. 23 right panel allows the 
contains at least one subgroup called "Development". The administrator to mcxlify the subgroups of which colleend is 
"Development" subgroup contains at least one subgroup 45 a member. The administrator does this by clicking on an 
called NCoD. Subgroup "NCoD" contains a number of appropriate box corresponding to a desired subgroup. If the 
subgroups, such as ConfigFW 58, which have no children. box is clear (meaning that colleend is not presently a 
Also in this example, subgroup "Development" is selected member), then a check mark is added to the box to include 
in the expansion tree. Since "Development" is not at the top colleend in the subgroup. Conversely, if a subgroup box is 
of the tree hierarchy (the "All Users" group), the notebook 50 already checked, then clicking on the box clears the check 
shown in the right pane! is somewhat different from that of mark and removes colleend from the subgroup. 
FIG. 15 when "User Groups" was selected, because all users FIG. 24 shows the right panel when the Applet Permis- 

are not automatically a member of "Development", as they sions tab of FIG. 22 is selected by the administrator. In this 
are of "User Groups". The list 1820 displays the log-on right panel, list 2420 displays all applets that are defined in 
system IDs of all system members. The status beside each 55 the system. The administrator can permit access by colleend 



user ID in list 1820 shows whether the user owns a mem- 
bership in the "Development" subgroup. A status of "yes" 
indicates that the user is a member of the "Development" 
subgroup, "no" indicates that the user is not a member of the 
"Development" subgroup, and "inherited" indicates that the 
user inherits membership within the "Development" group 
by belonging to at least one of Development *s subgroups 
further down the tree. A user's membership status for a 
subgroup is modified by the administrator by selecting the 
user in list 1820 and then clicking on the "Add to Group*' 
button 1836 or "Remove from group** button 1838. If the 
administrator wishes to create a new system user, or modify 



60 



65 



to an applet by selecting the applet in list 2420 and then 
clicking the "Permit user access'* button 2430; or access can 
be denied to colleend by clicking the "Deny user access 
button" 2432. The administrator can also launch an applet in 
the context of colleend by clicking the "Run/Customize** 
button 2434. When this is done, the applet selected in list 
2420 is launched in the right panel. The administrator can 
then modify any preferences thai the applet allows and save 
the preferences in the manner provided by the applet. A 
t>'pical scenario here is for the administrator to launch a 
configuration applet then to fill in a variety of preference 
fields. However, if a separate configuration is not provided 
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for a user applet, the administrator can launch the user applet 
in the context of a user and set preferences from the user 
applet. A typical scenario here is for the administrator to 
select a group or user context and then to launch the user 
applet as described above. The administrator can then typi- 
cally modify preferences from an options menu and save 
them in any manner provided by the user applet. For 
example, typically, the user preferences are saved when the 
options dialogue is closed, or the user applet may provide 
other methods of saving the preferences. In any event, since 
the administrator is running the applet in the context of 
colleend in this example, the preferences set up by the 
administrator through the user applet are saved on the server 
as if colleend had entered them directly herself by running 
the applet. 

Not shown in the figures is a scenario whereby a user can 
modify some preferences that pertain to a user applet- For 
example, a user applet may allow a user to select a window 
background color or fonts and font sizes, so that each system 
user can individualize the applet to some extent when the 
user applet executes on the users desktop. In this case, the 
user modified preferences are saved in the same way as they 
are when the administrator runs the user applet. One 
difference, however, is that the administrator can run user 
applets to set preferences in group contexts, whereas users 
can only affect preferences for their individual context. 

It is to be understood that the above described arrange- 
ments are merely illustrative of the application of principles 
of the invention and that other arrangements may be devised 
by workers skilled in the art without departing from the spirit 
and scope of the invention. 

What is claimed is: 

1. In a network system comprising a network intercon- 
necting a server and a plurality of user stations, wherein the 
server stores configuration preferences for the end user 
applications in contexts of different groups and subgroups of 
users, a method of storing the configuration preferences on 
the server, said method comprising 

providing a profile manager at an administrators station, 

arranging the profile manager to execute a configuration 
appHcation for an end user application, whereby the 
administrator can specify configuration preferences for 
the end user application in contexts of different groups 
and subgroups of system users, 

determining a unique location on the server for storing the 
configuration preferences for the end user application 
in a selected context by 

retrieving a fully qualified class name of the end user 
application from an object on the administrator's sta- 
tion which represents the configuration application, 
whereby the fully qualified class name uniquely differ- 
entiates the application from other object classes, 

combining the fully quaUfied class name with the selected 
context to form a key, and 

mapping the key in a prescribed manner to generate the 
unique storage location address. 

2. The method of claim 1 further comprising 

at a user's station, responsive to a request to execute a user 
application, requesting from the server a user context, 

at the user station, combining the user context with the 
fully qualified name of the user application to form the 
key, and 

requesting configuration preferences for the application 
by sending the key to the server to identify the storage 
location of the preferences. 

3. In a network system comprising a network intercon- 
necting a server and a plurality of user stations, wherein the 
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server stores configuration preferences for the end user 
applications in contexts of different groups and subgroups of 
users, an arrangement for storing the configuration prefer- 
ences on the server, comprising 
5 a profile manager at an administrators station, 

means allowing the profile manager to execute a configu- 
ration application for an end user application, whereby 
the administrator can specify configuration preferences 
for the end user application in contexts of different 
10 groups and subgroups of system users, 

means for determining a unique location on the server for 
storing the configuration preferences for the end user 
application in a selected context, including 
means for retrieving a fully qualified class name of the 
15 end user application from an object on the adminis- 

trator's station which represents the configuration 
application, whereby the fully qualified class name 
uniquely differentiates the application from other 
object classes, 

20 means for combining the fully qualified class name 
with the selected context to form a key, and 
means for mapping the key in a prescribed manner to 
generate the unique storage location address. 

4. The arrangement of claim 3 further comprising 

25 means at a user's station responsive to a request to execute 
a user appfication for requesting from the server a user 
context, 

means at the user station for combining the context with 
the fully qualified class name of the user application to 
^0 form the key, and 

means at the user station for requesting configuration 
preferences for the application by sending the key to 
the server to identify the storage location of the pref- 
erences. 

5. A computer storage media having program code seg- 
ments stored thereon for use in a client-server network 
having a server and a plurality of user stations for deter- 
mining a unique server storage address for storing configu- 
ration preferences for end user applications in contexts of 

^ different groups and subgroups of users, the media compris- 
ing 

a first code segment for providing a profile manager at an 
administrators station, 

a second code segment for arranging the profile manager 
to execute a configuration application for an end user 
application, whereby the administrator can specify con- 
figuration preferences for the end user application in 
contexts of different groups and subgroups of system 

50 "^"^ 

a third code segment for retrieving a fully qualified class 
name of the end user application from an object on the 
administrator's station which represents the configura- 
tion application, whereby the fully qualified class name 
uniquely differentiates the application from other 
object classes, 

a fourth code for combining the fully qualified class name 
with the selected context to form a key, and 

a fifth code segment for mapping the key in a prescribed 
5Q manner to generate the unique storage location address. 

6. The media of claim 5 further comprising 

a sixth code segment for use at a user station and 
responsive to a user request to execute an application 
for requesting from the server a user context, 
65 a seventh code segment for use at the user station for 
combining the user context with the fully qualified 
name of the user application to form the key, and 
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an eighth code for use al the user station for requesting 
configuration preferences for the application by send- 
ing the key to the server to identify the storage location 
of the preferences. 
7. A computer program embodied in a carrier wave and 5 
containing program code segments stored for use in a 
client-server network having a server and a plurality of user 
stations for determining a unique server storage address for 
storing configuration preferences for end user applications in 
contexts of dififerent groups and subgroups of users, the lo 
program further comprising 

a first code segment for providing a profile manager at an 

administrators station, 
a second code segment for arranging the profile manager 
to execute a configuration appfication for an end user 
application, whereby the administrator can specify con- 
figuration preferences for the end user application in 
contexts of different groups and subgroups of system 
users, 

20 

a third code segment for retrieving a fully qualified class 
name of the end user application from an object on the 
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administrator's station which represents the configura- 
tion application, whereby the fully qualified class name 
uniquely differentiates the application from other 
object classes, 
a fourth code for combining the fully qualified class name 

with the selected context to form a key, and 
a fifth code segment for mapping the key in a prescribed 
manner to generate the unique storage location address. 
8. The computer program of claim 7 further comprising 
a sixth code segment for use at a user station and 
responsive to a user request to execute an application 
for requesting from the server a user context, 
a seventh code segment for use at the user station for 
combining the user context with the fully qualified 
name of the user application to form the key, and 
an eighth code for use at the user station for requesting 
configuration preferences for the appfication by send- 
ing the key to the server to identify the storage location 
of the preferences. 

* ♦ ♦ * * 



07/08/2002, EAST Version: 1.03.0002 



